Encouraging developers help testers

Although there are many reasons to include manual testing in the development process, it shouldn't be the bottleneck that you describe (even though this is a very common situation).

The mindset of developers needs to change. Their role is not to just write code, but solve problems and produce a high quality product. That means also helping to test the product to ensure that it is of sufficient quality. However, since they are developers, their skills may be more closely aligned with automated testing rather than manual testing. Are your developers writing automated unit, integration, system, and acceptance tests? Have they integrated these automated tests into a build pipeline so they can get rapid feedback on their changes? Writing good tests that find issues early in the development process can shorten the feedback loops.

If you don't have automated tests now, you can start adding them. At the highest levels, the manual test cases that the testers run may be good candidates for initial automation. The QA team can help the developers to prioritize what tests to automate - maybe they know of tests that are painful to set up and execute or maybe they know tests that have found regressions in the past. This can foster a spirit of collaboration between the developers and the testers.

Rather than pulling new items from the backlog, the developers should be making sure that new work has automated tests and work to fill in any gaps related to old work. Developing these tests may reveal issues, either functional or technical debt, in the product that may be worth solving in the Sprint, rather than starting new work.

However, if manual testing is necessary to get work to Done within a Sprint, a developer needs to understand that the team takes on the work and the team finishes it. Although the preference is to use the strengths of every individual, that may not always be possible and a developer may need to contribute to manual testing in order to make sure that work is done and that the Increment is fully integrated and potentially releasable.

If the automated testing done by developers goes well and there's an overall mindset change to improve quality, the manual testing should be much easier. In an ideal state, the manual testers would be focusing early on testability and interesting test cases (ideally that would be automated during the development process, to the extend possible) and late on exploratory testing or situations that may be difficult to effectively automate.

My team has 3QAs who are doing manual GUI testing and 5 developers.  The situation is QAs are always busy and cannot handle all the testing that comes from developers.

As professionals, what are the team doing to ensure that these tests will soon be automated with coverage to a “Done” standard and with regression packs in place?

I know of a similar situation where the testers were told to grow their skillset by learning to do some basic coding (HTML and Javascript) and help the developers with repetitive, maintenance or cosmetic tasks. On the other hand, the developers were asked to help the testers out as needed.

Weekly lunch and learn sessions were scheduled to have the developers/testers learn from each other. During the week, some time was set aside for pair-programming for developer/tester pairs.

The team didn't self-organize which is why management had to make the decision for them. 

Management came to the conclusion that going forward, only 360 degree candidates (those can can code, test and write stories) would be hired. And those who were resistant would be coached by their line managers to their new responsibilities. A few developers quit, the rest adapted and with new 360 degree candidates, the development culture changed for the better.

At the end of the day, what was best (long-term) for the business and for the customer took precedence.

Eager to know on how we can encourage developers on QA testing.

I agree that this is a mindset and that it would take some time but I would like to know on how you start encouraging them or at least get to try the efforts to do testing.

I had a different perspective in discussing this issue on our teams and they responded differently. I think not only the developer mindset, but also QA's mindset to reach out on how their devs can begin on doing qa testing.

Tests are a real complex discipline.

I myself as a dev allways suggest to the P.O to talk to the sponsor to pay Udemy or something like these to all devs.Maybe even Scrum.org could have a course or certification for this,because its probably the biggest source of friction in teams.

I wrote this post in linkedin,and Iḿ reposting here even to validate my views with more experienced Scrum practicioners.

Strategies so that QA doesn't become the bottleneck in the Sprint.

First of all, Scrum doesn't recognize any difference between developers; QA is considered to be a developer.
The discipline of testing must be respected, it is as deep as systems development, but the ideal is for each developer(programmer) to improve their testing skills, learning about integration and functional testing is a must.
If the team has a dev who specializes in testing (read QA), then he or she should act as a test advisor, help develop the test plan, ratify the tests done by each dev, as well as doing their own, but finding an error in this phase should be an exception, which can be discussed in the sprint retrospective.
Our test-savvy DEV can be responsible for setting up the automated test pipeline as well.
Scrum is a framework for product development, not just software, can a developer be a wall painter, do all your devs program in Java, or Oracle? No, then QA is a dev and that's that.

One dev testing another's work before passing it on to our QA specialist usually gives good results.
Testing should be part of the definition of done and the definition of workflow(for those teams that use Kanban), to avoid overloading QA and leaving everything to the last minute.
A good Scrum Master should know about WIP, and workflow definition, to help the team in their definitions.Scrum is a framework that can be adapted to the company's reality and practices (not to be confused with relaxed Scrum).
The more the P.O. understands the product, and is able to turn it into good stories, the less stakeholders are needed for UAT testing, but there's nothing to stop stakeholders from lending a hand with testing, which is especially useful when the team is working with complex legacy systems.
It's very important that our knowledgeable test dev actively participates in refining the backlog.

Although the review shouldn't be seen as a portal for sending value to production, it is expected that most of what has been agreed will be demonstrated at the end of the sprint. It's not worth leaving everything for QA to check on the Thursday before the review, when it's often too late to fix anything.
If something is defective, it doesn't match the definition of done, and it shouldn't be demonstrated in the review.
Although continuous delivery reduces the pressure of delivery in the review, it shouldn't be done for flaws in the process.

Well I don´t know what is taught and what is required in the Dev certification, In Brazil nobody cares about this  certification,and maybe they should.

Do this certification  emphasize importance and best practices when related to tests?

If so, these can help in the  question

Eager to know on how we can encourage developers on QA testing.

Well I don´t know what is taught and what is required in the Dev certification, In Brazil nobody cares about this  certification,and maybe they should.

If you are talking about the PSD I, well it covers minimum:

1. Test-Driven Development (TDD) – Automated tests created before the code is written to validate that we need that code.
2. Acceptance Test-Driven Development (ATDD) – Tests, either automated or manual, that validate business functionality
3. Behaviour Driven Development (BDD) – An automated test that validates a particular behaviour that you want your application to have.

The Applying Professional Scrum for Software Development™ Training covers:

• The Scrum Framework
• Working within a Scrum Team
• Definition of Done
• Backlog management practices and slicing features
• Code quality and Technical Debt
• Agile architecture practices
• Test Driven Development
• Pair Programming
• Agile Testing and other practices to ensure quality

• Using DevOps with Scrum

   

Thanks,So SMś should really encourage devs to at least attend this course.